1. Field of the Invention
The present invention is directed to operating systems and real-time operating systems as well as systems and techniques for developing the same, and in particular it is directed to operating systems and real-time operating systems for processors that have easily configurable features.
2. Background of the Related Art
Operating systems (OSes) and real-time operating systems (RTOSes) provide basic software services required by a variety of software applications. An OS or an RTOS brings together in one package the basic services that are common to many applications. By doing so, the OS or the RTOS keeps the application developer from duplicating those basic services within each application. For reasons described in greater detail below, the following discussion will focus on RTOSes; however, it should be kept in mind that the information disclosed herein is also applicable to OSes.
Most of the basic features supplied by an RTOS are not specific to features supplied by a particular processor. Only a small fraction of the services that an RTOS supplies are specific to a particular processor. For example, an operating system often manages basic input and output operations. Traditional POSIX-style I/O interfaces require many things that are not processor-specific. At the same time, however, I/O usually requires interaction with processor-specific features like interrupts. Consequently, operating systems in general group such processor-specific features into a unit and define an interface to that unit. Different operating systems use different names for this interface: the VxWorks(copyright) RTOS from Wind River Systems, Incorporated of Alameda, Calif. calls this layer the architecture layer; Windows NT(copyright) calls it the HAL; and the Nucleus RTOS from Advanced Technology, Incorporated of Mobile, Ala. has no specific name for the interface, but simply provides an implementation in a small set of files which are referenced in their portability documentation.
In all cases, this set of services (called herein the abstraction layer) is designed as a convenience to the operating system""s higher-level features. Consequently, this abstraction layer varies from one RTOS to another, and the functionality it provides is specific to the operating system even though part of the implementation is specific to a processor.
As a result, the implementation of this abstraction layer becomes a combination of processor-specific coding and operating system coding. If either the processor or the operating system changes, the implementation of the abstraction layer needs to be modified. Such a manual reimplementation of operating system services when the processor is modified becomes especially problematic in the case of a configurable processor.
The problem of different members of traditional processor families offers a limited parallel to the problems of a configurable processor. Operating systems have, to date, dealt with these problems using several different methodologies applied to the architecture layer of the operating system.
The first of these methodologies is source code preprocessor directives that allow the user to include code for all of the processors in a single module. In this case, modules in the architecture layer are instrumented with preprocessor directives. Which processor is being supported is selected at compile time by the build system. The other code, though included in the source code, is not in the object code.
There are difficulties with this method. Code that is not being compiled is not being tested for correctness. Since the interface to sections of code switched with the preprocessor directives is ill-defined, this is a source of common code breakage. Building the architecture layer for a particular configuration requires that all of the source code in the module be rebuilt, even though much of it may be processor-independent. Readability of the source code is often more difficult because of the additional complexity that the preprocessor directives introduce. Maintenance of the source code is made more difficult for the same reason.
The second of these methodologies is run-time determination of processor features. Consider several members of a processor family that differ from one another only by the size of the instruction cache. A set of code can be written that at run time determines the cache size.
There are difficulties with this method as well. Not all features can be successfully run-time detected. So, while presence of cache is available for detection, generation of certain interrupts may not be detectable. Determining processor configuration at run time can be less efficient as well in that more time is taken to determine the configuration. Also note that in the cases where family members extend the ISA using the same register indices and/or opcodes, it is even more likely that runtime detection will not be possible. This case is quite common for an extensible processor where different uses are extending the ISA at the same time.
The last of these methodologies is the creation of a separate source file for each member of the CPU family. This is a different expression of the first methodology.
The problems here related to the content of this source file. Because architecture layers are OS-centric rather than processor-centric, the content of these files has large content that is not processor-specific. When this content needs to change, the change must be propagated across all of the files. Since each CPU family member has its own file, again a maintenance problem is created.
OSes and RTOSes make use of the abstraction layer in different ways; for example, certain issues which make the abstraction layer appropriate for use with an RTOS are not present in the OS environment. On the other hand, many RTOS do not use ancillary devices such as MMU translators which can be abstracted by the abstraction layer for an OS.
A configurable processor is a processor that acquires different characteristics based on a user specification. In this case, the set of processor features that must be handled by the abstraction layer is not static and must adapt to different processor configurations. Today processors have been introduced in families with each member of the family containing a different set of features from the other members of the family; however, the number of processors in any given family has been relatively smallxe2x80x94especially when compared to the number of different processors that can be produced by a configurable processor generator.
Note, however, that not all processor configurations are substantially different from the operating system perspective. Changes to some configuration parameters are transparent to the operating system because these changes do not affect the processor at a software functional level and, thus, the operating system is not affected. For example, processor configuration include information about the technology that is to be used to create the processor. This configuration substantially affects the generation of the processor, but does not affect the software that runs on the processor. In the following discussion it is assumed that the phrase xe2x80x9cdifferent configurationxe2x80x9d implies a configuration on which an OS or RTOS produced for another configuration will not work properly due to the differences between the two configurations.
As mentioned previously, this abstraction layer consists of two separate conceptual components. The first component includes operating system-specific logic and functionality whereas the second component includes processor-specific logic and functionality. In existing solutions, these two components are meshed together. Such an implementation introduces significant problems when the abstraction layer must be reimplemented due to changes to the processor feature set. Because of the close interaction between the operating system and the processor functionality, the reimplementation can produce problems in either area of the abstraction layer.
Moreover, changes to the operating system demands of the abstraction layer can force reimplementation of the processor-specific sections of the abstraction layer because the two are intermingled. So, if the operating system changes in a way that drives a change into the architecture layer then, because of the intermingling of operating system-specific code and processor-specific code, the processor-specific code must be revisited as well. This causes additional expense, effort and time.
Even if the processor support were firmly and cleanly separated from the operating system support, changing the processor feature set would still require reimplementation of the processor portion of the abstraction layer for each configuration that had differences visible to the operating system. Such a manual reimplementation is error-prone and time consuming.
Finally, there are operating system support issues for differently configured processors. Some operating systems, such as the aforementioned VxWorks(copyright) system, are distributed in binary form; that is, they have been compiled prior to delivery. Such a compiled form includes both aspects of the abstraction layer, i.e., processor-specific logic and operating system-specific logic. Clearly, under such a model the precompiled version of the operating system cannot support different configurations of the processor.
The present invention has been made with the above problems of the prior art in mind, and it is an object of the present invention to provide an abstraction layer between an operating system and the underlying processor which is easily modifiable.
It is a further object of the present invention to provide an abstraction layer which is particularly suitable for use with a configurable processor.
It is another object of the present invention to provide an abstraction layer which can be easily reimplemented in response to changes in the feature set of the underlying processor.
It is a still further object of the present invention to provide an abstraction layer which has easily reimplementable portions corresponding to configurable processor features visible to the operating system.
It is yet another object of the present invention to provide an abstraction layer which provides a standardized and consistent abstraction interface over a number of operating systems.
It is a further object of the present invention to provide an abstraction layer between an operating system and an underlying configurable processor which can be generated from a description of the configurable processor features.
It is another object of the present invention to provide a system and method for generating an abstraction layer between an operating system and an underlying configurable processor from a description of the configurable processor features.
The above objects are achieved according to a first aspect of the present invention by providing a hardware abstraction layer as a system architectural layer operating between a real-time operating system and an underlying configurable processor. The hardware abstraction layer provides an abstraction of processor-specific functionality to the operating system. In particular, it abstracts configurable processor features visible to the operating system to provide a uniform, standardized interface between the operating system and the configurable processor on which it runs. Thus, an operating system running on top of the hardware abstraction layer will work on all configurations of the processor which differ from one another only in the configuration parameters covered by the hardware abstraction layer.
The above objects are further achieved according to a second aspect of the present invention by facilitating automatic generation of the HAL based on a processor description. Here, the same information that is used to describe the features being configured in the configurable processor is used to automatically generate a HAL appropriate to that processor. Automatic generation of the HAL greatly eases use of the HAL and the configurable processor, since the user is not required to manually write the HAL or adapt an existing one based on the processor configuration parameters.